GESTION DU DEVELOPPEMENT 


Que faire des projets 


«à problèmes» ? 


La dérive des projets suit quelques scénarios types... et 
conduit à des décisions difficiles: recadrer, geler ou stopper. 
L'expérience et les décisions de quelques grands utilisateurs. 


es projets à problèmes, beau- 
D coup d'entreprises en ont et 

en auront. Il ne faut pas se 
mettre la tête dans le sable. Les 
méthodes de gestion de projet ne 
sont pas toujours faciles à mettre 
en œuvre, et surtout elles ne sont 
pas infaillibles. Il arrive aussi 
qu'aucune règle de gestion de pro- 
jet ou de bon sens ne soit appli- 
quée. Le tout est de détecter ces 
projets à temps et de les gérer. 
Avec trois solutions: les recadrer, 
les «geler» et les arrêter. Dans 
tous les cas, leur «dissection» 
s'avère instructive, révélant même 
parfois des difficultés qui dépas- 
sent largement le cadre initial du 
projet: organisation, communica- 
tion, stratégie, management, tech- 
nique. 

Mais comment en vient-on là? 
A quelques variantes près, le pro- 
blème émerge au terme de l'un 
des scénarios suivants: syndrome 
de la grenouille, perfectionnisme, 
problèmes de couple. Quelques 
projets les cumulent tous. 

«Pour résoudre un besoin réel, 
on peut faire beaucoup de choses 
inutiles», note Jean Demougin, 
délégué au système d’information 
à France Télécom (direction des 
programmes et des finances), qui 


a pour mission de surveiller les 
projets. Ce syndrome «de la gre- 
nouille» voit un projet utile grossir 
démesurément au fil des mois. 
Parce que, consciemment ou 
non, le ou les responsables en pro- 
fitent pour étendre leur territoire 
personnel. 

Autrefois répandu dans les très 
grandes entreprises, ce syndrome 
fait l’objet d’une surveillance at- 
tentive. Mais il reste vivace. Au- 
jourd'hui, les utilisateurs poussent 
plus souvent à la roue que les in- 
formaticiens.. contraints de jouer 
un rôle de frein qui ne leur 
convient guère: «ll est difficile 
pour une direction informatique 
de se battre pour ne pas faire un 
projet», avoue un directeur infor- 
matique. 


De la trop 
belle ouvrage 


Autre expression du syndrome: 
dès qu'un projet est mis en 
exergue, tout le monde veut y rac- 
crocher son wagon. Un projet 
phare attire les désirs non assouvis 
de l’entreprise: fonctionnalités, 
technologies, applications, pou- 
voir, reconnaissance. ils trouvent 
là un point de cristallisation. Le 


projet devient alors tellement 
complexe que plus personne ne le 
domine vraiment. 

La spirale du perfectionnisme 
naît, elle, de la volonté de bien 
faire (voir article ci-dessous), On 
vise à satisfaire pleinement les uti- 
lisateurs, faire un beau projet. «Le 
désir de la belle ouvrage s'ob- 
serve en particulier chez les ingé- 
nieurs», note Jean Demougin, qui 
constate une tendance à dévelop- 
per des machines à tout faire. Ce 
fut le cas d’un projet de système 
d'information... sur le système 
d’information de France Télécom, 
dont le budget risquait d'atteindre 
plusieurs millions de francs. Alors 
qu'une application sous Excel 
pouvait faire l'affaire. 

«Les utilisateurs acceptent des 
solutions partielles qu'ils ont bri- 
colées sur le micro. Mais, quand 
ils ont affaire à l'informatique, ils 
exigent la perfection», explique 
Nicole Hernandez, ingénieur de 
recherche au service informatique 
de gestion du ministère de l'Edu- 
cation nationale. Légitime et 
louable au départ, le désir de trai- 
ter 100% du problème peut entraf- 
ner loin. Les quelques derniers 
pour cent coûtent le plus cher. En 
temps et en argent. N'oublions pas 


La spirale du perfectionnisme 


P our une fois, ils avaient eu le 
temps de tout faire dans les 
règles de l’art! Les responsables 
du projet GME (Gestion des 
moyens des établissements) au 
service informatique de gestion du 
ministère de l'Education natio- 
nale, ne cachent pas leur surprise. 
Après deux ans d’études et de dé- 
veloppements, respectant tous les 
canons de la gestion de projet, le 
projet a été gelé. 


Pierre-Yves Duwoye voit le . 


côté positif de la décision: «Cela 
prouve que les garde-fous fonc- 
tionnent et que nous sommes ca- 
pables de trancher. Cela a valeur 
pédagogique». Il ne s'agissait 
ni d'un grand projet (environ 
3 hommes/année) ni d’une appli- 
cation critique. Autant en faire un 
s d'école. 

Les leçons de cette expérience? 
Tout d'abord que production et 
aide à la décision n'appellent pas 
la même informatique. «C'est cul- 
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turellement un autre monde. Nous 
avons appliqué des méthodes tra- 
ditionnelles alors qu'il faut trou- 
ver d'autres approches. Quand un 
outil est indispensable et qu'il n'y 
a pas de temps à perdre, les utili- 
sateurs sont plus réalistes et on 
peut se permettre d'être plus di- 
rectif. Avec l'aide à la décision, 
on touche un domaine beaucoup 
plus subjectif». 

Dans le cadre de sa nouvelle 
mission «qualité et méthode», Ni- 
cole Hernandez, ingénieur de re- 
cherche au service informatique 
de mission du ministère, lait aussi 
l'exégèse du projet GME, qu'elle 
a, en partie, piloté. Les causes de 
ce «loupé» ne sont pas techniques. 
Le prototype final fonctionne 
bien. 

Son ergonomie de type Win- 
dows n'est pas mise en cause. 
Mais on le juge trop complet, trop 
lourd à mettre en œuvre, par rap- 
port à un besoin qui n’est pas si 


pressant. Ent par l’enthou- 
siasme et les exigences des de- 
mandeurs, les informaticiens se 
sont lancés dans un projet trop 
ambitieux. 

De plus, les représentants des 
établissements n'étaient sans 
doute pas suffisamment représen- 
tatifs des attentes de leurs col- 
lègues. La dimension psycholo- 
gique n’a pas été prise en compte. 
Or, si certains chefs blis 
ment cherchaient à optimiser ! 
fectation de leurs ressources, 
d'autres reproduisaient la même 
structure d'une année sur l'autre 
sans se poser de questions. Utili- 
ser l'outil supposait une méthode 
de travail nouvelle. «Comme le 
projet avait été développé à la de- 
mande des utilisateurs, nous 
avons pensé qu'il était vendu 
d'avance. C'était apparemment 
une erreur», conclut Nicole Her- 
nandez. 


S.H.-D 


Pierre-Yves 


Hemandez: 


la tentation technicienne, qui fait 
céder aux sirènes des technologies 
dernier cri, qu'elles se justifient 
où non. 


Problèmes de couple 


Aujourd’hui dominent les «pro- 
blèmes de couple». De belles 
étiquettes formalisent les rela- 
tions: maître d'ouvrage, maître 
d'œuvre. mais la communication 
entre informaticiens utilisateurs ne 
coule pas de source pour autant. 
Malentendus, tensions, manques 
de coordination, voire guerres de 
tranchées continuent à miner plus 
d'un projet. Ils conduisent à des 
erreurs d'appréciation des besoins, 
à des rectifications fonctionnelles 
et techniques incessantes, à des 
sommes de détails jamais réglées 
qui font dériver complètement le 
développement. 


Des symptômes 
visibles 


Détecter les problèmes à temps re- 
lève des managers ou d’une tierce 
personne chargée de mission au- 
près de la direction générale, ou 
du responsable de la qualité. Un 
rôle souvent difficile pour 
quelqu'un d'extérieur au projet. 
Les délais offrent le premier cri 
tère à surveiller. Au premier écart, 
il faut regarder de plus près, m: 
sans tirer de conclusions hâtives 
Un retard, chose courante, ne suf- 
fit pas à classer un projet comme 
«problématique». Sauf s'il dé- 
passe les bornes, bien sûr. 

«Un projet qui marche est 
transparent, constate Jean De- 
mougin. Quand les informations 
ne remontent pas facilement, 
quand les explications ne se lais- 
sent pas comprendre aisément, 
c'est mauvais signe». Autre indi- 
cateur, le «radiomoquette». Si l'on 
entend parler d'utilisateurs insatis- 
faits, ou de climat mauvais, il faut 
aller voir. Bref, rester à l'écoute 
de tous les petits signes et bran- 
cher son sixième sens. En cas de 
doute, faire une enquête person- 


nelle et éplucher les documents 
(cahier des charges, budgets, rap- 
ports d'étape). Les convictions se 
précisent par le déroulement 
même de l'enquête: «Personne 
dans le projet ne disait la même 
chose», se souvient le délégué au 
système d'information de France 
Télécom à propos d’un projet ré- 
cupéré de justesse. 


Recadrer, 
geler ou stopper 


Une fois le suspect détecté, il faut 
agir. Parfois on peut rattraper le 
projet par les cheveux. Soit en 
simplifiant le cahier des charges. 
soit en nommant un vrai réspon- 
sable. On peut aussi reprendre le 
projet, le confier à une équipe de 
pompiers. On n'oubliera pas de 
prévoir alors des éléments de me- 
sure tangibles pour suivre la 
marche vers les objectifs. 
Dans d’autres cas, on peut geler 
le projet, l'arrêter sur un état 
stable et renoncer aux étapes ulié- 
rieures. C'est ce que fait France 
Télécom, avec son projet de factu- 
ration Frégate, dont la première 
phase, déjà développée, est dé- 
ployée, mais qui n'ira pas plus 
loin, C’est la seule issue quand on 
ne contrôle pas le projet et qu'il a 
une importance stratégique. 
L'arrêt complet s'impose par- 
fois comme le moindre mal 
Quand, par exemple, la stratégie 
de l'entreprise ou les besoins des 
utilisateurs ont changé, quand les 
délais ou les coûts d'un projet im- 
portant mais non vital échappent à 
tout contrôle, ou enfin quand les 
utilisateurs le rejettent sans appel. 
Comme l'explique Jean Demou- 
gin, les ressources sont limitées et 
continuer un projet mal parti peut 
empêcher d'en faire un autre. 
beaucoup plus stratégique. L'arrêt 
d'un développement peut même 
prendre une valeur pédagogique 
efficace: il signale une volonté de 
changement, il dégage la voie vers 
de nouveaux progrès. Mais les in- 
téressés en souffrent toujours 
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